Hello everyone,For command"preparetomove", I have some questions: 1, Suppose thatIneed todetach/re-attach a content database within a farm.Then should I use "preparetomove" before detachingthe content database?Fromformer experience,Ineed to use it for avoiding a Full Crawl. But from Todd's blog: http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx He mentioned that there is no need to use preparetomove anymore since the DB's ID won'tchange after the Infrastructure updateinstalled(We have installed it). And he also stresses that"PrepareToMove" sets 'Moving' to True in the SiteSynch table of the SSP DB which signals to the profile sync job to ignore the DB which has the effect of not allowing profile syncs to occur for the DB.This means using"preparetomove" willstop the profile sync on that DB.If so, we shouldnotusethe command anymore in this situation, is that correct?2, From Microsoft'sarticalfor "Preparetomove": http://technet.microsoft.com/en-us/library/cc262122.aspxIt stresses that Before moving a site collection between content databases, the preparetomove operation must be run in order to ensure all user membership metadata are correctly preserved.This meansweMUST use it for site collection's move between content databases. If so, willitstop the Profile Sync on that site collection? Or stop syncthe DB which hosting that site collection?3,From the MS artical above, it mentioned that Administrators run preparetomove before doing operations that result in change content databases ID or site collection ID.Then what action can cause the content database ID or site collection ID changes (suppose that the Infrastructure update has been installed)? Sample 1: If we move content database or site collectionto adifferent farm, then doesthis situationbelong to a change ofthe ID? And should we use preparetomove? Will it cause the Profile Sync stop? Sample 2: If wemove a site collection to another site collection as a new subsite,and Iuse export/import command to accomplish it. Then should I also need to use preparetomovebefore export the site collection (if the new site collection ishosted on another content database)?I am very sorry for askingso many questions, but Iam really veryvery confused about this command now. And if it really stop Profile Sync on our site collections orContent databases,we can't use it unless we findout solutions tofix it,and it is really the last thing we want tosee:-( Therefore, your kindly reply will beavery great help for me! Thank you all in advance :-)Roy

Short answer - if you have infrastructure update do NOT use this command - problem is you are looking at msft docs that were written before the IU was released and that doc has not been updated to reflect the IU changes.Gary Lapointe, Blog: http://stsadm.blogspot.com/, Twitter: http://twitter.com/glapointe

Hi Gary,Thanks for your reply.Although we can't see the Updated Timeon this artical when weread it now,I rememberclearly when Isawit at the first time, it shows this artical isupdatedat2/4/2009. I am pretty sureof this date sinceme and my colleaguetalked about the date when we saw the document. And the released date ofIU should be much earlier than it.Best Regards,Roy

Hi Roy, MVP: Gary Lapointes answer is correct. You must not run preparetomove after installed Infrastructure Update. The preparetomove operation was introduced before Infrastructure Update, and the Preparetomove: Stsadm operation (Office SharePoint Server) (http://technet.microsoft.com/en-us/library/cc262122.aspx) introduced how to use the command only (that's why it doesn't mention theInfrastructure Update). We were aware of the confusion and updated the articles recently, you should find an Important mark in Deploy software updates for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc263467.aspx) If you have installed the Infrastructure Update (http://go.microsoft.com/fwlink/?LinkID=133363&clcid=0x409) or later, you must not run preparetomove. Let me know if you need further assistance. -lambert Lambert Qin | Microsoft Online Support Engineer How to ask a question in the forum (http://support.microsoft.com/kb/555375) Posting is provided "AS IS" with no warranties, and confers no rights.

Hi Lambert,Thank you very very much. Your answercompletely solved my confusion, and reallyhelps me so much:-)Gary, thank you very muchtoo. Bless both of youhappy everyday :-)Best Regards,Roy

Hi Lambert, I'm trying to determine whether or not I need to issue the 'preparetomove' command when moving content DBs from one farm to another. I have SP2 installed but I'm unsure about which "infrastructure update" is involved here and how to determine if it's installed or not? Anthony :-)

Hello IrishChieftain10,If you have installed SP2, then the Infrastructure update is involved. It is because the SP2 includes all the updats released up to it. You can check the link below for detailed info:http://technet.microsoft.com/en-us/library/cc263467.aspx Best Regards,Roy

I'm not sure whether this preparetomove issue is over.i updated my farm from sp1 + infrastructure to SP2 + June package and still having this error.I disconnected the contentdbs, updated, renamed some dbs and reconnected them:Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: Profils utilisateur Event ID: 5553Date: 14/10/2009Time: 16:00:35User: N/AComputer: xxxxxxxDescription:failure trying to synch site dbabd74b-123a-4710-9939-8be3ba88bd91 for ContentDB 6f5585b8-6934-467a-99d1-9e1ae2d80e18 WebApp c3764098-1974-4d02-9834-c894cdff0202. Le message de l'exception était Cannot insert duplicate key row in object 'dbo.UserMemberships' with unique index 'CX_UserMemberships_RecordId_MemberGroupId_SID'.The statement has been terminated.. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Hi eSaid,please read this, it might help you solve your issue. http://blogs.technet.com/corybu/archive/2007/06/01/detaching-databases-in-moss-2007-environments.aspxAlso, i think that a little detail is missing from that post and that is in the command line: stsadm -o preparetomove -contentdb sqlserver:dbname -oldcontentdb <GUID> i think that the dbname should not be any name but should be the name of the new contentDB that used to have the oldcontentdb GUID in question, now i struggled a bit to find out how to get the new ContentDB for every old GUID in the list. and here is my solution:1. Go to SQL server and select the records from the SSP database table "SiteSynch". It will look like ContentDB id Site ID LastSync 01b05082-882e-4b6b-926b-9b18dbf6dee4 8d3b94be-812d-4dfa-b375-462754b7b9c2 15/09/2009 8:00:14 PM 2. Now you know the site ID for the OldDB GUIDs and you need to know the current ContentDB name. Execute the following code to get a list of site collections URLS and IDs with their content DBs (the WebAppUrl is the url for your web application) public string[] EnumSiteColl(string WebAppUrl){using (SPSite siteCollection = new SPSite(WebAppUrl)) { SPWebApplication webApp = siteCollection.WebApplication; string[] s = new string[webApp.Sites.Count]; int i = 0; foreach (SPSite site in webApp.Sites) { s[i] = site.Url + ": " + site.ID + ": " + site.ContentDatabase.Name + ": " + site.ContentDatabase.Id; i++; }return s; }}

What Lambert Qin and others above say, is in direct contradiction to published Microsoft technet information. Should we believe information posted by unknown users on a social blog, or should we believe the official Microsoft documentation? ref: http://technet.microsoft.com/en-us/library/cc262122.aspx I'm not asking rhetorically; this is a serious question. How do we know whether to trust official Microsoft documentation, versus posts in a social forum?

"...information posted by unknown users..." Unknown users? Anyone who doesn't recognise the names of those pre-eminent MVPs must've been living in a cave for the last few years. FYI, it is neither unknown nor uncommon for MSDN docs to carry out-of-date or erroneous information. In fact it's really quite de rigeur ! :D If at first you don't succeed, ask an MVP. Or find someone who really knows. ;)